ci: push production image to DockerHub alongside GHCR#3069
Conversation
The production workflow's "Login to DockerHub" step actually targeted ghcr.io, so production images were only ever pushed to GHCR. Add a real Docker Hub login and emit both registry tags, matching staging. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Appwrite WebsiteProject ID: Tip MCP server integration brings LLM superpowers to Claude Desktop and Cursor IDE |
Greptile SummaryThis PR fixes a long-standing misconfiguration where the production workflow's "Login to DockerHub" step was actually authenticating against
Confidence Score: 5/5Safe to merge — the change is a direct copy of the staging workflow's working pattern applied to production, with no functional risk to the existing GHCR push or the deploy job. The diff is a minimal, mechanical alignment of the production workflow with staging. Both registry logins use pinned action SHAs already present in the file, the secrets are the same ones staging already relies on, and the build-push step is unchanged except for the added DockerHub tag. No logic in the deploy job is touched. No files require special attention. Important Files Changed
Reviews (1): Last reviewed commit: "ci: push production image to DockerHub a..." | Re-trigger Greptile |
2 participants
Problem
The production deployment workflow never pushed images to DockerHub. The step named "Login to DockerHub" actually had its
registry:set toghcr.io, so production only ever authenticated against and pushed to GHCR. Staging, meanwhile, already pushes to both registries.Changes
DOCKERHUB_USERNAME/DOCKERHUB_TOKENsecrets (same as staging).REGISTRY_GITHUB,REGISTRY_DOCKERHUB, andIMAGE_NAMEenv vars.ghcr.io/appwrite/website:<tag>docker.io/appwrite/website:<tag>The production-only
SENTRY_RELEASEbuild-arg is left untouched.Notes
DOCKERHUB_USERNAME/DOCKERHUB_TOKENrepo secrets being available to release events — staging already uses them.🤖 Generated with Claude Code